Don't proceed with implicit search if result type cannot match - the search
will likely by under-constrained, which means that an unbounded number of alternatives
is tried. See strawman-contrib MapDecoratorTest.scala for an example where this happens.

This caused nested ambiguity errors with the next commit.

Propagate implicit ambiguity and divergence failures from implicit arguments
to their callers. In particular, and ambiguity in an implicit argument means
that the whole implicit search is ambiguous. Previously, the local ambiguity
translated to an "implicit not found" on the next outer level, which meant that
another implicit on that level could qualify and the ambiguity would be
forgotten.

The code is still a bit rough and could profit from some refactorings.

This is a temporary fix. iterator-from seems to cause
non-deterministic ambiguity errors. Moving to pending until
we have figured out what goes wrong.

Refactoring of implicits with the aim of clearer code and better error
messages. Here's an example:

    -- Error: implicitSearch.scala:15:12 -------------------------------------------
    15 |    sort(xs)  // error (with a partially constructed implicit argument shown)
       |            ^
       |no implicit argument of type Test.Ord[scala.collection.immutable.List[scala.collection.immutable.List[T]]] was found for parameter o of method sort in object Test.
       |I found:
       |
       |    Test.listOrd[T](Test.listOrd[T](/* missing */implicitly[Test.Ord[T]]))
       |
       |But no implicit values were found that match type Test.Ord[T].

Turns out it's not transitive when combined with the old scheme. So it
should be one or the other. Conservatively, this commit reverts to the old
scheme.

The aim is to have ultimately fewer comparisons. The downside is
that some of the comparisons are now more expensive, because types
have to be compared where they previously weren't.

 - Merge `rankImplicits` and `condense` into one phase
 - Fix handling of ambiguities - the previous unconditional
   abort was wrong, because another alternative might be
   better than both ambiguous choices.

All tests pass, and it is unclear what this is trying to achieve.

We now treat a type as an implicit function type also if it is
a type variable that has an IFT as upper bound in the current constraint.
This means we now create implicit closures if the expected type is
such a type.